\documentclass{assn}
\num{Lab 2 Final Comments}
\by{Ian Voysey (iev@), Ryan Hofler (rhofler@)}
\due{9 September 2008, 23:50 + 1 Late Day}
\for{15-440: Fund. Systems}
\begin{document}
\section{Enums}
The addition and wide spread use of enumeration types made this version far
more succinct and readable than its predecessor. They removed the item class,
got rid of hordes of magic numbers, and introduced compile time type-safety
for much of the code. The only potential loss in performance here came with
the addition of a \texttt{java.util.EnumMap} instead of a standard array in
the \texttt{Player} class, but the API assures us that this performs within a
small factor of a real array---good enough for me.

\section{The IO Hack}
The worst section of code in this version is far and away the IO code in
\texttt{Chips440.java}; it is, in almost every way, hard coded to have only
one or two players. Any 15-111 student could see how this would be generalized
using the collections classes, and we in fact implemented some large swaths of
such a generalization. The code was discarded eventually, partly because of
the catastrophic overhead it introduced for something that would only ever be
two-player, but mostly because its use going forward was not clear.

In this revision, the game can only reasonably support two players per
map. Not only did we not design larger maps (as we said we wouldn't), there's
a very real physical limit to how many players can fit around one computer and
have enough keys to trade items and move---even two's a crowd. In contrast, in
a networked version, there's no reason to impose any such restriction, and the
code in \texttt{Engine.java} does not make any such assumption.

In order to force the full generalization to $n$ players on the lowly Lab $2$
environment, we would have to utterly destroy the abstraction boundaries by
passing a full player list to the IO class. In this case, I believe this
indicates a flaw in the idea more than a flaw in the object model. This object
model is designed to be almost a client-server set up already, to allow for a
rapid transition to networked code, and in that light, having one client know
all of the data about every other client is utterly unacceptable and alien.

So in some sense, we believe, this class is gross because it must be. Due to
the design we put forth in previous iterations of the lab, having multiple
players on one machine is a bit of a red herring, and demands a good amount of
hackish behaviour. This could be eliminated, but the runtime cost is large,
and it's not code that's useful for the future.

\section{Caching of Resources}
The addition of larger maps pointed out to us that we had totally forgotten to
write any sort of cache for images or sounds. The maps we wrote previously
were small enough that not only did we not mind the disk-read latencies
introduced by loading, they actually lent fluidity to play. This borrowed
fluidity went away quickly with a $36 \times 36$ map. So we wrote a cache that
guarantees each resource (sound or image) is loaded into memory once and
exactly once.

\section{Concurrency Control}
There are three hot-spots of concurrency issues in this version: the
\texttt{java.util.HashMap} of move queues in the \texttt{Engine} class; item
trading; and the use of the board. Interestingly, their solutions were both
quite simple.

The seemingly more complex issue of the \texttt{HashMap} doesn't actually
create any problems. The threads associated with each player wake up and
process the queues, and since the player ID's are by choice unique, these
queues are disjoint and associated uniquely. The \texttt{HashMap} is not
involved in the processing of these queues, as each player's thread has a
reference to that player's queue. Therefore, there is no concurrent access here.

Item trading is similarly disjoint, and therefore safe.

The issue of tiles was resolved by first making a convenient choice of
invariant, and secondly by synchronizing a few choice methods. We chose to let
players stand on the same tile. There's no reason that they should need to,
but there's no motivating reason to bar it either. This allows the board to
exist in the wild without a big lock on it, and this is greatly appealing. It
does, however, introduce an issue with items---players should not be allowed
to dupe items simply by getting lucky. This was taken care of by simply
synchronizing the \texttt{okToStep} methods in each \texttt{Tile} subclass
which have any interaction with items.
\end{document}
